[SSF-145] - Cognito integration account creation by dburkhart07 · Pull Request #113 · Code-4-Community/ssf

dburkhart07 · 2026-02-21T03:22:21Z

ℹ️ Issue

Closes #145

📝 Description

This PR goes into the process of creating a new user through Cognito. Our existing Auth Service that utilized the Cognito API required a password, so we needed to use a new one that generates a temporary password, and emails it to the new user that we want to create.

When the user enters their temporary password for the first time, amplify stores a challenge that tells us that we need to create a new permanent password. Because of this, we needed to add in a new frontend modal into what we already had. From there, we can get the user cognito client sub, which is what we now store in our database.

The pantry and food manufacturer flow is slightly different, as they have linked users which are already created as they wait for approval after filling out the application. Because of that, we implement a check to see what their role is to determine if we update it in the database, or create a new user.

✔️ Verification

Run the following steps:

Tested users receive emails only when their email does not exist
Was able to successfully reset my password through the frontend UI
Verified pantries and food manufacturers that do not have an account receive an email, but no additional user is created (just sets the cognito client sub)

🏕️ (Optional) Future Work / Notes

Pending testing being written for this.

maxn990

Great first pass!

In addition to the comments I left, I found one more bug I wanted to mention. After I create an account as a pantry, the first time I try to access the dashboard after creating my account I get the following problem:

It's fine after I refresh though

apps/backend/src/auth/auth.service.ts

apps/backend/src/pantries/pantries.service.ts

apps/backend/src/users/users.controller.ts

apps/frontend/src/containers/loginPage.tsx

apps/backend/src/users/users.service.ts

maxn990 · 2026-02-23T01:57:35Z

apps/backend/src/auth/auth.service.ts

+      return sub;
+    } catch (error) {
+      if (error.name == 'UsernameExistsException') {
+        throw new ConflictException('A user with this email already exists');


if there is an email conflict doesn't it make more sense to notify the user when they submit the application rather than the admin who is approving/denying the application? there isn't really anything the admin can do if they find that an email already exists in the db other than reach out directly

hmm this is a good question, and likely related to product.

for the pantry and food manufacturer flow: a DB user should be created with an empty cognito sub when the application is submitted. we could make an api call to check if the primary email exists in cognito and throw an error otherwise (since having a cognito account makes them an official user) and not allow for modal submission.

for admin and volunteers: this is a little harder, since i am not quite sure what our frontend flow is going to be for creating these two yet. how is this email going to be obtained from the frontend?

@sam-schu @Yurika-Kan

I think checking if the primary email already exists in cognito to allow for modal submission is a good solution for pantry and food manufacturer

For admins and volunteers, the email will be provided directly (we do already have volunteer creation in the frontend on the admin volunteer management page). But for all four user types, a user should only have a cognito account if they also have a db user, so checking that the email does not already exist in our own db should be sufficient to know it won't exist in cognito (so the check you added here should hopefully never need to activate, but it should be fine to have it as a failsafe). I did have it written down in my list of future work to deal with the case where we try to create a user with an email that already exists, so I don't think you need to worry about updating the existing db user creation flows to account for that in this PR.

Makes sense to not worry about it in this pr. Just want to raise one potential case for us to think about if we decide to check against the db in the future.

If an application gets rejected, and they re-apply, it won't let them submit their application again because they already have an account in the db even if they don't have a cognito account

Based off the client meeting today, our flow of applying/rejecting may change. Based on this, I think it may be best to hold off on this logic for now. Definitely good to keep in mind right now though.

yep! with how they're planning on handling approving/denying the re-application scenario should not be an issue

maxn990 · 2026-02-23T02:02:01Z

apps/backend/src/auth/auth.service.ts

+        { Name: 'email', Value: email },
+        { Name: 'email_verified', Value: 'true' },
+      ],
+      DesiredDeliveryMediums: ['EMAIL'],


I think we should change the email from the default to 1) indicate that their application was approved and 2) provide further information other than simply the password, like how to access the signup page, or even a link to the application. When I got the email I wasn't quite sure what to do with it

You can look at my cognito docs for instructions on how to change the default email, lmk if you have any questions

how to access this page will definitely change, but we can just put the link as localhost for right now, and change it later, so i like the idea of more information on what to do with the password as well.

the application approved sounds good too, but im not sure if there is a separate automated email for that. i know in many modern flows (for example, email verification after you submit a job application), you receive 2 emails: one saying your application was submitted, and another being to verify your email. if we have a separate one for this, i suggest we keep the template basic on how to setup the account.

I'm fine to table this discussion for now since the email template can be easily changed without code later.

If the intended flow is to have two emails that's fine with me, although it seems easier to implement and simpler to just have 1 email from cognito rather than having a call to cognito and a call to ses.

apps/frontend/src/containers/loginPage.tsx

maxn990

looks really good! a few small things but otherwise looks great 🥳

apps/backend/src/pantries/pantries.service.ts

apps/backend/src/auth/auth.service.ts

maxn990 · 2026-02-24T04:50:30Z

apps/backend/src/pantries/pantries.service.spec.ts


  // Approve pantry by ID (status = approved)
  describe('approve', () => {
-    it('should approve a pantry', async () => {


Why was this removed? We now don't have a test for if the pantry approval process works.

I think we should be asserting the following:

mockUsersService.create was called with the right DTO
mockRepository.update was called with { status: 'approved', pantryUser: newPantryUser }

fixed the test

dburkhart07 added 4 commits February 20, 2026 22:10

Final commit

e63be34

Final commit

eea6561

Final commit fr this time

9cc525f

Merged main

33e1acd

Juwang110 self-requested a review February 23, 2026 00:51

maxn990 requested changes Feb 23, 2026

View reviewed changes

dburkhart07 added 2 commits February 23, 2026 02:32

Implemented fixes

0977f43

Final changes

0d2536f

dburkhart07 requested a review from maxn990 February 24, 2026 04:04

maxn990 requested changes Feb 24, 2026

View reviewed changes

Fixed test

77b06cb

Comments

Conversation

dburkhart07 commented Feb 21, 2026

ℹ️ Issue

📝 Description

✔️ Verification

🏕️ (Optional) Future Work / Notes

Uh oh!

maxn990 left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

maxn990 left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

maxn990 left a comment •

edited

Loading